Snap Forensics: A Tradeoff between Ephemeral Intelligence and Persistent Evidence Collection

Digital evidence needs to be made persistent so that it can be used later. For citizen forensics, sometimes intelligence cannot or should not be made persistent forever. In this position paper, we propose a form of snap forensics by defining an elastic duration of evidence/intelligence validity. Explicitly declaring such a duration could unify the treatment of both ephemeral intelligence and persistent evidence towards more flexible storage to satisfy privacy requirements

Agree to Disagree: Security Requirements Are Different, But Mechanisms For Security Adaptation Are Not

We describe a dialogue between a proponent and an opponent of the proposition "security is not just another quality attribute in self-adaptive systems". The dialogue is structured in two steps. First, we examine whether security requirements are different from other system-level requirements. Our consensus is that security requirements require specific methods for elicitation, reasoning, and analysis. However, other requirements (such as safety, usability and performance) also require specific techniques. Then, we examine the adaptation mechanisms for security and compare them with other properties. Our consensus is that most adaptation techniques can be applied to maintain security and other requirements alike

Miki: a wiki for synchronous modeling of software requirements

Eliciting a high quality requirements model that can be traced down to implementations is a challenge. Keeping models updated for evolving software systems is a further challenge. Formal modelling methods are one approach - but one that is too rigid and costly for many small software engineering companies [1]. We propose a light-weight alternative, using a wiki as the synchronous bridge between requirements capture and more formal modeling features of the IDE such as Eclipse

Concerns and their separation in feature diagram languages: An informal survey

Feature diagrams describe valid configurations of features in a product. As feature diagrams play a central role in software product line development, several concerns are reflected in them, contributing to their increasing size and complexity. The way that those concerns are recognised and separated in feature diagrams affects our ability to manage them effectively. However, the nature of important concerns in software product line development, and the extent to which the separation of concerns is addressed by current research and practice is not clear. In this paper, we report on our initial survey of important concerns considered by feature diagram languages and guidelines for addressing those concerns

Using problem descriptions to represent variabilities for context-aware applications

This paper investigates the potential use of problem descriptions to represent and analyse variability in context-aware software products. By context-aware, we refer to recognition of changes in properties of external domains, which are recognised as affecting the behaviour of products. There are many reasons for changes in the operating environment, from fluctuating resources upon which the product relies, to different operating locations or the presence of objects. There is an increasing expectation for software intensivedevices to be context-aware which, in turn, adds further variability to problem description and analysis. However, we argue in this paper that the capture of contextual variability on current variability representations and analyses has yet to be explored. We illustrate the representation of this type of variability in a pilot study, and conclude with lessons learnt and an agenda for further work

Composing features by managing inconsistent requirements

One approach to system development is to decompose the requirements into features and specify the individual features before composing them. A major limitation of deferring feature composition is that inconsistency between the solutions to individual features may not be uncovered early in the development, leading to unwanted feature interactions. Syntactic inconsistencies arising from the way software artefacts are described can be addressed by the use of explicit, shared, domain knowledge. However, behavioural inconsistencies are more challenging: they may occur within the requirements associated with two or more features as well as at the level of individual features. Whilst approaches exist that address behavioural inconsistencies at design time, these are overrestrictive in ruling out all possible conflicts and may weaken the requirements further than is desirable. In this paper, we present a lightweight approach to dealing with behavioural inconsistencies at run-time. Requirement Composition operators are introduced that specify a run-time prioritisation to be used on occurrence of a feature interaction. This prioritisation can be static or dynamic. Dynamic prioritisation favours some requirement according to some run-time criterion, for example, the extent to which it is already generating behaviour

Challenges and Barriers Recruitment of Professionals and Management Trainees in a Transitional Situation to the New Normal

The purpose of this study is to find out the obstacles faced in recruiting professional and management trainees in the transition situation to the new normal. Competition in the global business world requires company management to be more concerned in managing human resources in it. However, in the new normal situation, several challenges and obstacles in professional recruitment are difficult to attract Candidates with the Right Qualifications, Incomplete Company-Related Information, Ineffective Channels Used, Limited Access to Required Devices and others. All recruitment processes including selection can be done online, the right solution during a pandemic

On the structure of problem variability: From feature diagrams to problem frames

Requirements for product families are expressed in terms of commonality and variability. This distinction allows early identification of an appropriate software architecture and opportunities for software reuse. Feature diagrams provide intuitive notations and techniques for representing requirements in product line development. In this paper, we observe that feature diagrams tend to obfuscate three important descriptions: requirements, domain properties and specifications. As a result, feature diagrams do not adequately capture the problem structures that underlie variability, and inform the solution structures of their complexity. With its emphasis on separation of the three descriptions, the problem frames approach provides a conceptual framework for a more detailed analysis of variability and its structure. With illustrations from an example, we demonstrate how problem frames analysis of variability can augment feature diagrams